FIG. 1 gives a highly schematised representation of an internetwork (or portion of an internetwork) such as the Internet. An internetwork is an arrangement in which the networks of two or more different operators are interconnected and arranged to communicate according to a common internetworking protocol or protocols. An internetwork typically connects multiple cities or countries, and is to a certain extent generally unhierarchical in nature. The Internet is by far the most widespread and commonly used example of an internetwork, defined by the use of Internet Protocol (IP) or the Internet Protocol Suite.
As shown in FIG. 1, each of a multitude of end-user terminals 2a, 2b, 2ψ . . . such as desktop computers, laptops, tablets or mobile handsets is connected to at least one routing node 4a, 4b . . . 4w of at least one network service provider. Similarly each of multiple servers 3a . . . 3d is connected to at least one of the routing nodes 4. Each connection may comprise one or more wired and/or wireless stages, e.g. involving a wired modem connection to a telephone landline, a wired local area network (LAN) 5, and/or a wireless connection via a wireless router, or a wireless connection via a packet-based service of a mobile cellular network. Only one local area network (LAN) 5 is shown in FIG. 1 for illustrative purposes, but it will be appreciated that generally many more of the connections between user terminal 2 and its immediate upstream node 4 may be by a LAN. Further, in the case of connection by a wireless router, this may effective form a connection via a small wireless local area network (WLAN), not shown explicitly in FIG. 1.
Each of the routing nodes 4 is directly connected to at least one other adjacent routing node 4, such that each of the service provider nodes 4 are all at least vicariously interconnected to one another. Directly connected here means requiring one only routing hop at the internetwork level, whereas vicariously connected means two or more routing hops.
In operation, an end-user terminal 2 generates packets of data destined for another of the user terminals 2 or servers 3, or vice versa, with the destination being identified by means of an internetwork network address such as the IP address included in a header portion of each packet. The end-user terminal 2 then transmits the packets upstream to a routing node 4 of its local network service provider to which it is directly connected. Each routing node 4 is configured to examine the internetwork address (e.g. IP address) of an incoming packet received from a user terminal 2, server 3 or routing node 4; and based on that address to forward the packet onwards to a next routing node 4 or to the destination user terminal 2 or server 3, as appropriate depending on the current routing node's location within the internetwork relative to the destination. Hence the packet is routed via multiple routing nodes 4 from the source user terminal 2 or server 3 to the destination user terminal 2 or server 3.
Some of the routing nodes such as those labelled 4a-4em, 4i-4l and 4p-4s may handle local traffic (e.g. within a particular city), being directly connected by local links to one or more other local routing nodes (e.g. in the same city). Some of the routing nodes such as those labelled 4f, 4g, 4m, 4n, 4t and 4u may handle intranational traffic (e.g. between cities or states), being directly connected by intranational links to one or more other intranational routing nodes (e.g. in other cities or states). Some routing nodes such as those labelled 4h, 4o and 4w may handle international traffic, being directly connected by one or more international links (e.g. overseas) to other international routing nodes in other countries. Furthermore, each local routing node may also connect directly onwards to one or more intranational or international nodes, and/or each intranational node may connect between one or more local routing nodes and one or more international routing nodes. It will be appreciated however that the connections shown in FIG. 1 are only for illustrative purposes, and that in general a much more complex arrangement is likely to be in place. In practice an internetwork such as the Internet is likely to comprise many more user terminals 2, servers 3 and routing nodes 4 at various levels of geographical interconnection than shown in the schematic illustration of FIG. 1, and the routing nodes 4 are not necessarily divided into strict levels of local, international and international nodes (e.g. an international routing node could also connect directly to end-user terminals or one or more servers 3, etc.).
As mentioned, the routing nodes 4 include nodes operated by a plurality of different operators in the form of network service providers (not all of whom are necessarily direct providers to end-users), and the different network service providers have mutual routing agreements with one another. E.g. two network service providers operating within the same city or state, or two network service providers operating in different countries, may have a mutual agreement to route each other's customers' traffic therebetween.
However, there is a problem with such arrangements in that it is difficult to collect information on network resources. Over time, any particular routing node or nodes 4 may experience varying amounts of traffic. Further, different routing nodes 4 may experience different amounts of traffic at different times, and/or different routing nodes may have different capacity for routing different quantities of traffic per unit time (e.g. different queue lengths or processing power). These or other variations in network resources can result in different negative properties such as packet-loss, latency (delay), or decreased bitrate being experienced at a destination terminal or terminals 2 or 3, e.g. due to routing bottlenecks at certain routing nodes or nodes 4.
It would be useful to know such information, e.g. for network planning purposes, but the intrinsically distributed, non-centralised, multi-provider nature of a large internetwork such as the Internet makes this a very difficult task.
Some Internet service providers (ISPs) install monitoring equipment in cities, but this fails to give information on delivery to actual individuals (e.g. the packet loss or latency as experienced by the end user).
Some ISPs also ask their users to download dedicated applications which they run on their end-user terminals 2 so as to help analyse network performance. However, these are only limited to collecting data on resources within the network of one ISP and do not give a wider picture across the internetwork.
It would be desirable to provide an improved system, method and/or software tool for collecting information on network resources in a packet-based internetwork such as the Internet.